Recently, communication networks have widely spread and are used in every day life by many users. Among such communication networks, so-called packet switched communication networks find increasing attention. Packet switched networks transmit/receive data in units of packets. A packet consists of a header carrying control information such as (among others) for example a packet's address information (source/destination) as well as of a payload section carrying the actual data such as voice or the like.
Various protocols exist for such packet switched communication. For the purpose of the present invention, however, as an example of such protocols, IPv4 and/or IPv6 are described (which are versions of the well known Internet Protocol IP). Notwithstanding this, other packet switched protocols are useable in connection with the present invention. Also, non-packet switched protocols can be used in connection with the present invention, as long as the source/destination are identifiable by means of addresses.
Communication networks normally form part of a communication network system in which networks of plural operators cooperate with each other. Also, an individual network may consist of plural so-called domains of a network with the network as such being operated by a network operator, but the domains being e.g. controlled by a respective third party (different from the network operator), being operated on a different protocol, or having a different address space definition, or the like. Thus, for the purpose of the present invention, when communication networks are concerned, it is not distinguished between different networks or different domains, but communication networks are intended to cover all possible alternatives of the above outlined network constitution. Rather, a communication network could be regarded as a communication network system.
In connection with such communication networks or network systems, respectively, security issues become more and more important.
Normally, a communication is established/ongoing between two terminals. A communication originating terminal is referred to as first terminal or user equipment UE, and a communication destination terminal is referred to as correspondent node CN or second terminal. Of course, in a bidirectional communication, the correspondent node CN also acts as a user equipment UE when responding to the originating terminal. Technically, there need not be any difference between the terminals, but nevertheless, the terminals may be different from a technical point of view. Any difference, however, does not matter as long as the terminals are adapted to communicate with each other by means of the intermediate communication network.
In case a communication is or has been established between two terminals, the communication is identified by the source and destination addresses of the terminals. Also, as the communication may involve different contents or types of traffic to be exchanged between the terminals such as real-time traffic and non-real time traffic, a respective traffic is associated to a respective port. A port or port number thus represents a refinement of the address information used in the communication.
Unused addresses or even port numbers, however, constitute a possibility for attackers to establish a fraudulent or misbehaving communication to a user's terminal who does not actually wish to have such a communication.
Therefore, security issues in communication networks become more and more important. So-called firewalls FW play an important role for guaranteeing security in communication networks. A firewall can thus be regarded as a filtering node in a communication network which filters un-authorized traffic and prevents such traffic to reach a terminal which did not authorize such traffic to be received.
This invention is related to such security issues and filtering nodes or firewalls, respectively. It is more particularly related to the dynamic configuration of pinholes in firewalls and to the support of real-time services in communication. The expression “pinhole” as used in the present invention denotes a temporarily valid permission for a specific traffic to reach a specific terminal, which permission is granted or rejected by the firewall. An open pinhole thus represents the granted permission, whereas a closed pinhole represents the rejected permission.
In many frameworks of communication networks, there is the need to dynamically open and close pinholes in firewalls. For example, SIP (Session initiation protocol) established communications require pinholes to be dynamically created for the media stream (i.e. UDP/RTP for real-time services (User datagram protocol, real time protocol), TCP (transmission control protocol) for Instant Messaging) to pass through the firewall and for data packets to be exchanged between the communicating nodes (originating terminal and correspondent node terminal). These pinholes should then be removed (i.e. closed) at the termination of the communication to avoid possible attacks.
Subsequently, the architecture and more particularly the network entities as well as the interfaces that have been introduced and adopted in 3GPP (3rd generation partnership project) networks for the interworking of IPv6 with IPv4 domains are briefly described with reference to FIG. 1. This shows that the present invention as described in the following sections does not introduce new entities but re-uses an existing communication network architecture and the thus adopted framework in an innovative way.
The architecture as illustrated in FIG. 1 has been recently adopted in 3GPP for the interworking of IPv6 and IPv4 domains. However, this description serves as an example only and the present invention is not limited to Ipv4/IPv6 domains but is intended to cover also situations in networks within a single domain. Also, the functionality of the entities and interfaces that have been introduced are briefly outlined.
The subsequent sections will then explain how the present invention re-uses the currently already existing infrastructure in an innovative way to solve the firewall traversal problem.
Now, as is derivable from FIG. 1:
The current interworking architecture relies on a Translator Gateway: The TrGW is a gateway that converts the IP headers as needed, more generally, converts or translates address information included in the packets to be transmitted.
The current interworking architecture also relies on an IMS (IP Multimedia Subsystem) Application Layer Gateway (ALG): The IMS ALG's functionality is to provide the necessary application function for SIP/SDP protocol stack in order to establish communication between IPv6 and IPv4 SIP applications (Session Initiation Protocol/Session Description Protocol).
The IMS ALG receives an incoming SIP message from CSCF nodes (Call state control function, there are defined a S-CSCF, Serving CSCF and an I-CSCF, Interrogating CSCF) or from an IPv4 SIP network domain (CSCF's such as a (proxy) P-CSCF, S-CSCF, or I-CSCF are also referred to as SIP server in this application). This domain can be an external domain but may also be an internal domain of the communication network. The IMS ALG then changes the appropriate SIP/SDP parameters, translating the IPv6 addresses to IPv4 addresses and vice versa. Note that for the present invention, the protocols IPv4/IPv6 are only examples and other protocol transitions are conceivable.
The IMS ALG modifies the SIP message bodies and the headers that include the IP address. The IMS ALG will request NA(P)T-PT (Network Address (and Port) Translation-Protocol Translation) to provide the bindings data between the different IP addresses (IPv6 to IPv4 and vice versa) upon session initiation, and will release the bindings at session release. The NA(P)T-PT is thus a kind of a stateful translator and maintains an IPv6/IPv4 mapping table.
An Ix interface between the TrGW and the IMS ALG has also been introduced and adopted. Such interface shall allow:
the IMS ALG to request the NA(P)T-PT to provide the bindings data between the different IP addresses (IPv6 to IPv4 and vice versa) upon session initiation,
the TrGW to provide the bindings data to the IMS ALG, and
the IMS ALG to release the bindings at session release.
Furthermore, FIG. 1 depicts a user equipment UE operating based on IPv6 (which communicates with a correspondent node (not shown) CN operated based on IPv4. Also, a Proxy-CSCF (P-CSCF) is illustrated which receives a “first hop” signaling information from the user equipment UE when initiating a communication or session. The I-CSCF and S-CSCF can be regarded as a so-called call processing server CPS which represents an example of a communication management node. Additionally, a domain name server DNS and home subscriber server HSS form part of the architecture. The above described entities are mainly involved in the signaling and communication management as indicated by the dotted line which indicates signaling traffic, whereas the payload data is transmitted from the user equipment UE via the IP-CAN (IP Connectivity access network) through the translator gateway TrGW towards the communication partner, i.e. the correspondent node (not shown), as indicated by the bold line denoted “bearer” in FIG. 1.
As persons skilled in the art are considered to be familiar with the general architecture and the entities/nodes with the individual functions thereof, a further detailed description is omitted here.
Firewalls filter IP packets based on filtering rules, typically considering the source and destination IP addresses, the protocol type and/or the port numbers. In order to avoid attacks, firewalls are configured with filtering rules. Such rules include static rules (e.g. to stop TCP flooding or specific protocols) and dynamic rules (pinholes). Several applications require dynamic pinhole configuration in the firewall. As an example, SIP communications require dynamic creation/removal (i.e. opening/closing) of pinholes in the firewall for the media stream to pass the firewall while blocking attacks (UDP flooding, etc.) More generally, UDP (user datagram protocol) based applications require dynamic pinholes to be opened/closed when the communication starts/stops. Note that the description of SIP serves as an example only and that other protocols may also be used in connection with the present invention, such as e.g. WAP (Wireless Application Protocol), or the like.
Hitherto, several solutions have been proposed for dynamic pinhole control in firewalls, which are briefly introduced below:
1. The Use of Fake UDP Packets:
According to this approach, the user equipment UE sends a dummy UDP packet and the firewall FW opens the pinhole based on such packet. However, there is no way for the firewall FW to determine when the pinholes should be closed (since UDP communication does not have a session establishment/tear down as TCP does). Alternatively, the user equipment UE can send dummy UDP packets to create the pinhole in the firewall FW and will maintain sending such dummy UDP packets by a periodic transmission of such packets. Such method however presents two major problems: (1) the user equipment UE does not have any knowledge concerning timers of the state created in the firewall FW and (2) this may result in a high number of bytes to be sent over the wireless link, thus wasting resources.
2. The Use of a Firewall FW Which is Aware of e.g. SIP:
A SIP aware FW which will parse the SIP signaling and open/close the pinholes as required. This, however, requires SIP signaling to be visible at the firewall, while, however, SIP compression may be applied (e.g. in 3GPP and 3GPP2 IMS) and the firewall FW may not be capable to decompress it. Moreover, this solution gives too much control to the firewall FW, and the network operator at least partly looses control (whereas it is generally preferable to maintain the control in one's own products and/or networks). Finally, this solution cannot be applied when IPsec (Internet Protocol (IP) security) or TLS (transport layer security) encryption is applied to protect the SIP.
3. The Use of an Interface Between the Firewall FW and the Application Server (e.g. SIP Server in IMS):
Although such interfaces are being defined (e.g. MIDCOM in IETF (MIDCOM: Middlebox Communication as being under definition by IETF, Internet Engineering Taskforce), they are still in an early specification stage, the standardization work may require some time and their availability in products is far away, whereas systems (e.g. IMS) need to be deployed before the firewall FW will support such interfaces. Moreover, although this solution allows for the control to be in a manufacturer's products (e.g. SIP server), the deployment is not fully independent from products from other companies.
4. A Signaling Protocol from the Terminal UE to the FW in Order to Perform Configuring of the FW:
The TIST protocol (topology insensitive service transversal), the CASP protocol (cross application signaling protocol) and other contributions are suggesting a signaling protocol from the terminal opening and closing the necessary pinholes in the firewalls in the network. These methods are however still individual drafts and it will take a very long time before such solutions will become standardized.